漏洞环境
seeyon 8.1 sp2
分析
密码重置接口逻辑
1 | /seeyon/individualManager.do?method=resetPassword |
对应com.seeyon.v3x.personalaffair.controller.IndividualManagerController类的resetPassword方法
从代码中不难看出，需要longName不为null、canModify参数为true 才会进入到重置密码的功能点，canModify和loginName是从session中获取。
在致远中修改密码的流程中，首先是需要输入对应的手机号或者邮箱信息，提交修改密码请求后，服务端会向对应手机号或者邮箱发送验证码信息，用户获取到验证码再提交是否正确，验证成功后会将用户名存放至session中，并在session中添加canModify为true代表已经成功验证，最后请求如下接口修改密码；修改密码的逻辑并没有什么问题，存在问题的点在于校验验证码的功能点。
 |
|---|
校验验证码接口
1 | /seeyon/personalBind.do?method=sendVerificationCodeToBindNum&type=validate |
对应com.seeyon.v3x.personalaffair.controller.PersonalBindController的sendVerificationCodeToBindNum方法
在286行处，漏洞的关键点在于从request中获取了origin参数，值为zx，那么就会在session中设置canModify为true，进入此处，只需要设置type为validate即可。
 |
|---|
上面的密码重置逻辑和校验验证码逻辑可以看出都是基于同一个Session下进行操作，都是从session中获取用户的信息。
getBindTypeByLoginName方法就是从request中获取loginName， 并将loginName存入Session中。
 |
|---|
 |
最后访问/seeyon/personalBind.do?method=retrievePassword，输入目标系统中存在的用户名，提交，就会自动将信息绑定到Session中。
 |
|---|
漏洞复现
访问/seeyon/personalBind.do?method=retrievePassword，输入系统中已有的用户名并提交
 |
|---|
访问/seeyon/personalBind.do?method=sendVerificationCodeToBindNum&type=validate&origin=zx 在session中将canModify设置为true
 |
|---|
最后 访问重置密码接口/seeyon/individualManager.do?method=resetPassword&nowpwd=123456
 |
|---|
修改成功